FHIR © HL7.org  |  Server Home  |  FHIR Server FHIR Server 3.4.11  |  FHIR Version n/a  User: [n/a]

Resource Requirements/FHIR Server from package hl7.fhir.uv.cmhaffr2#current (47 ms)

Package hl7.fhir.uv.cmhaffr2
Type Requirements
Id Id
FHIR Version R5
Source http://hl7.org/fhir/uv/cmhaffr2/https://build.fhir.org/ig/HL7/cmhaff-ig/Requirements-CMHAFFR2-PDS.2.html
Url http://hl7.org/fhir/uv/cmhaffr2/Requirements/CMHAFFR2-PDS.2
Version 2.0.1
Status active
Date 2025-01-30T10:38:20+00:00
Name PDS_2_Product_Risk_Assessment_and_Mitigation
Title PDS.2 Product Risk Assessment and Mitigation (Header)
Experimental False
Realm uv
Authority hl7
Description This category deals with process steps for risk assessment and mitigation for those who are developing a new app, or an upgrade to an app, prior to its being deployed to Consumers.
Purpose Degrees of risk should be assessed and mitigated according to the intended use of the app. In general, risk management should manage security, privacy, safety, and other types of risks such as potential app failure scenarios, events that could lead to undesirable outcomes, probability and severity of risk, and mitigations or resolutions. One size does not fit all. For example, if apps handle sensitive personal information or give health interpretation or advice, higher degrees of risk are involved than for apps that do not collect personal information or do not interpret or advise. If some information identified during this step should be disclosed to consumers, that is stated in the “Informing Consumers/Users” section

Resources that use this resource

No resources found


Resources that this resource uses

No resources found



Narrative

Note: links and images are rebased to the (stated) source

Generated Narrative: Requirements CMHAFFR2-PDS.2

PDS.2#01SHALL

The App SHALL conform to a product risk assessment and mitigation plan as outlined by the developer. This plan should explicitly determine what risk must be addressed through software coding, hardware adaptions, policy, and what residual risk will be accepted by the entity responsible for the app. The developer will need to maintain, review, and update organizational Risk Register to include risks associated with mobile application.

PDS.2#02SHALL

In development of the App, the developer SHALL follow secure coding and practices using an established risk assessment framework.

PDS.2#03SHALL

IF personally Identifiable Information is collected THEN in development the App SHALL be guided by risk assessment findings in terms of their potential effect on adequately securing an individual's personally identifiable information (PII) including any protected health information (PHI), and also information used to access an EHR/PHR (e.g., logon credentials).

PDS.2#04SHALL

IF the App transmits data to an EHR THEN the App SHALL document failure rates, measurement error rates, software bugs, and hardware risks of all types.

PDS.2#05SHOULD

Prior to product launch, the App SHOULD be approved in accordance with User Acceptance Testing (UAT) by testers who are not part of the formal development team.

PDS.2#06SHOULD

The App SHOULD be monitored and include documentation of conflicts or compatibility issues of the app with other apps, device features (e.g., camera), or connected devices.

PDS.2#07SHOULD

IF the App relies on external supporting infrastructure, (e.g., cloud-based servers) to operate, THEN the App SHOULD document measures to ensure the availability of that infrastructure.

PDS.2#08MAY

The App MAY provide documentation to show that the app publisher has adequate resources to continue to develop, maintain, and support the product (e.g., human resources, finances, IP rights, facilities, equipment, tools).


Source

{
  "resourceType" : "Requirements",
  "id" : "CMHAFFR2-PDS.2",
  "meta" : {
    "profile" : [
      "http://hl7.org/fhir/uv/cmhaffr2/StructureDefinition/FMHeader"
    ]
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p class=\"res-header-id\"><b>Generated Narrative: Requirements CMHAFFR2-PDS.2</b></p><a name=\"CMHAFFR2-PDS.2\"> </a><a name=\"hcCMHAFFR2-PDS.2\"> </a><a name=\"CMHAFFR2-PDS.2-en-US\"> </a><table class=\"grid\"><tr><td><b><a name=\"CMHAFFR2-PDS.2-01\"> </a></b>PDS.2#01</td><td><a href=\"http://hl7.org/fhir/R5/codesystem-conformance-expectation.html#conformance-expectation-SHALL\">SHALL</a></td><td><div><p>The App SHALL conform to a product risk assessment and mitigation plan as outlined by the developer. This plan should explicitly determine what risk must be addressed through software coding, hardware adaptions, policy, and what residual risk will be accepted by the entity responsible for the app. The developer will need to maintain, review, and update organizational Risk Register to include risks associated with mobile application.</p>\n</div></td></tr><tr><td><b><a name=\"CMHAFFR2-PDS.2-02\"> </a></b>PDS.2#02</td><td><a href=\"http://hl7.org/fhir/R5/codesystem-conformance-expectation.html#conformance-expectation-SHALL\">SHALL</a></td><td><div><p>In development of the App, the developer SHALL follow secure coding and practices using an established risk assessment framework.</p>\n</div></td></tr><tr><td><b><a name=\"CMHAFFR2-PDS.2-03\"> </a></b>PDS.2#03</td><td><a href=\"http://hl7.org/fhir/R5/codesystem-conformance-expectation.html#conformance-expectation-SHALL\">SHALL</a></td><td><div><p>IF personally Identifiable Information is collected THEN in development the App SHALL be guided by risk assessment findings in terms of their potential effect on adequately securing an individual's personally identifiable information (PII) including any protected health information (PHI), and also information used to access an EHR/PHR (e.g., logon credentials).</p>\n</div></td></tr><tr><td><b><a name=\"CMHAFFR2-PDS.2-04\"> </a></b>PDS.2#04</td><td><a href=\"http://hl7.org/fhir/R5/codesystem-conformance-expectation.html#conformance-expectation-SHALL\">SHALL</a></td><td><div><p>IF the App transmits data to an EHR THEN the App SHALL document failure rates, measurement error rates, software bugs, and hardware risks of all types.</p>\n</div></td></tr><tr><td><b><a name=\"CMHAFFR2-PDS.2-05\"> </a></b>PDS.2#05</td><td><a href=\"http://hl7.org/fhir/R5/codesystem-conformance-expectation.html#conformance-expectation-SHOULD\">SHOULD</a></td><td><div><p>Prior to product launch, the App SHOULD be approved in accordance with User Acceptance Testing (UAT) by testers who are not part of the formal development team.</p>\n</div></td></tr><tr><td><b><a name=\"CMHAFFR2-PDS.2-06\"> </a></b>PDS.2#06</td><td><a href=\"http://hl7.org/fhir/R5/codesystem-conformance-expectation.html#conformance-expectation-SHOULD\">SHOULD</a></td><td><div><p>The App SHOULD be monitored and include documentation of conflicts or compatibility issues of the app with other apps, device features (e.g., camera), or connected devices.</p>\n</div></td></tr><tr><td><b><a name=\"CMHAFFR2-PDS.2-07\"> </a></b>PDS.2#07</td><td><a href=\"http://hl7.org/fhir/R5/codesystem-conformance-expectation.html#conformance-expectation-SHOULD\">SHOULD</a></td><td><div><p>IF the App relies on external supporting infrastructure, (e.g., cloud-based servers) to operate, THEN the App SHOULD document measures to ensure the availability of that infrastructure.</p>\n</div></td></tr><tr><td><b><a name=\"CMHAFFR2-PDS.2-08\"> </a></b>PDS.2#08</td><td><a href=\"http://hl7.org/fhir/R5/codesystem-conformance-expectation.html#conformance-expectation-MAY\">MAY</a></td><td><div><p>The App MAY provide documentation to show that the app publisher has adequate resources to continue to develop, maintain, and support the product (e.g., human resources, finances, IP rights, facilities, equipment, tools).</p>\n</div></td></tr></table></div>"
  },
  "url" : "http://hl7.org/fhir/uv/cmhaffr2/Requirements/CMHAFFR2-PDS.2",
  "version" : "2.0.1",
  "name" : "PDS_2_Product_Risk_Assessment_and_Mitigation",
  "title" : "PDS.2 Product Risk Assessment and Mitigation (Header)",
  "status" : "active",
  "date" : "2025-01-30T10:38:20+00:00",
  "publisher" : "HL7 International / Mobile Health",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://www.hl7.org/Special/committees/mobile"
        }
      ]
    }
  ],
  "description" : "This category deals with process steps for risk assessment and mitigation for those\nwho are developing a new app, or an upgrade to an app, prior to its being deployed to\nConsumers.",
  "jurisdiction" : [
    {
      "coding" : [
        {
          "system" : "http://unstats.un.org/unsd/methods/m49/m49.htm",
          "code" : "001",
          "display" : "World"
        }
      ]
    }
  ],
  "purpose" : "Degrees of risk should be assessed and mitigated according to the intended use\nof the app. In general, risk management should manage security, privacy, safety, and other\ntypes of risks such as potential app failure scenarios, events that could lead to undesirable\noutcomes, probability and severity of risk, and mitigations or resolutions. One size does not fit\nall. For example, if apps handle sensitive personal information or give health interpretation or\nadvice, higher degrees of risk are involved than for apps that do not collect personal information or do not interpret or advise. If some information identified during this step should be disclosed\nto consumers, that is stated in the “Informing Consumers/Users” section",
  "statement" : [
    {
      "extension" : [
        {
          "url" : "http://hl7.org/fhir/uv/cmhaffr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "CMHAFFR2-PDS.2-01",
      "label" : "PDS.2#01",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The App SHALL conform to a product risk assessment and mitigation plan as outlined by the developer. This plan should explicitly determine what risk must be addressed through software coding, hardware adaptions, policy, and what residual risk will be accepted by the entity responsible for the app. The developer will need to maintain, review, and update organizational Risk Register to include risks associated with mobile application."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/fhir/uv/cmhaffr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "CMHAFFR2-PDS.2-02",
      "label" : "PDS.2#02",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "In development of the App, the developer SHALL follow secure coding and practices using an established risk assessment framework."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/fhir/uv/cmhaffr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "CMHAFFR2-PDS.2-03",
      "label" : "PDS.2#03",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : true,
      "requirement" : "IF personally Identifiable Information is collected THEN in development the App SHALL be guided by risk assessment findings in terms of their potential effect on adequately securing an individual's personally identifiable information (PII) including any protected health information (PHI), and also information used to access an EHR/PHR (e.g., logon credentials)."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/fhir/uv/cmhaffr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "CMHAFFR2-PDS.2-04",
      "label" : "PDS.2#04",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : true,
      "requirement" : "IF the App transmits data to an EHR THEN the App SHALL document failure rates, measurement error rates, software bugs, and hardware risks of all types."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/fhir/uv/cmhaffr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "CMHAFFR2-PDS.2-05",
      "label" : "PDS.2#05",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "Prior to product launch, the App SHOULD be approved in accordance with User Acceptance Testing (UAT) by testers who are not part of the formal development team."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/fhir/uv/cmhaffr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "CMHAFFR2-PDS.2-06",
      "label" : "PDS.2#06",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The App SHOULD be monitored and include documentation of conflicts or compatibility issues of the app with other apps, device features (e.g., camera), or connected devices."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/fhir/uv/cmhaffr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "CMHAFFR2-PDS.2-07",
      "label" : "PDS.2#07",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : true,
      "requirement" : "IF the App relies on external supporting infrastructure, (e.g., cloud-based servers) to operate, THEN the App SHOULD document measures to ensure the availability of that infrastructure."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/fhir/uv/cmhaffr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "CMHAFFR2-PDS.2-08",
      "label" : "PDS.2#08",
      "conformance" : [
        "MAY"
      ],
      "conditionality" : false,
      "requirement" : "The App MAY provide documentation to show that the app publisher has adequate resources to continue to develop, maintain, and support the product (e.g., human resources, finances, IP rights, facilities, equipment, tools)."
    }
  ]
}

XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.